In a publish/subscribe network a common technique is for each publish/subscribe engine in the network to send out proxy subscriptions for the topics that it actually has subscribers on. This proxy subscription informs the other publish/subscribe engines in the collective (a group of fully connected publish/subscribe engines) that if they receive a publication for the topic then they should forward it onto the publish/subscribe engine that sent out the proxy subscription. This reduces the network traffic as only a single publication needs to be sent to the publish/subscribe engine, which is then fanned out to all the local subscribers.
Proxy subscriptions are sent between publish/subscribe engines, so each publish/subscribe engine knows each other publish/subscribe engine's set of subscriptions and hence knows where to forward each publication according to its topic, avoiding the need to send all publications to all publish/subscribe engines. In conventional publish/subscribe networks, the topology does not assume any distinction between different publish/subscribe engines—all are equal and each publish/subscribe engine may wish to connect to any other—and so the propagation of proxy subscription information is either hierarchical (for a hierarchical publish/subscribe engine topology) or multicast to all publish/subscribe engines.
The technique of using collectives and proxy subscriptions does not enable groups of publish/subscribe engines to be defined inside a collective. A group of publish/subscribe engines may wish to serve a common goal. This goal might be delivering messages to subscribers that have a destination which can be directly accessed by any of the publish/subscribe engines in the group, for example, on a shared queue. An alternative might be if two publish/subscribe engines are desired to link between two collectives, but normally this would still create duplicates as each one would receive the publications and attempt to forward on to the other collective.